I don't know what to think about this :(

I understand your point about the UI and yes, it would be nice if the Update button did the right thing (doubly so for users not familiar with all this gettext stuff), but on the other hand:

1. Opening the file manually is not that big deal (not to mention required in OS X sandbox).
2. I'm far from sure that it is appropriate to have another private header for this. In most, if not all, cases, there's a single POT file alongside the PO translations, so why specify it there? Why not just pick the one file that's there alongside the PO? Unlike this patch, that would work without having to edit the PO file...

Eg. developing in CakePHP, the pot files are not alongside the po files but two directories up, which makes hand-selecting them a nuisance (adding to the clicks needed to open the menu and select "Update from POT").

I understand the reluctancy to have to many private headers.
Before I patched, I tried adding the path to the POT file to the Source Paths, but that didn't work. Maybe something can be done there?

I don't know anything about the OSX Sandbox rules, but is doesn't feel that different from going through the sources of a project?

Eg. developing in CakePHP, the pot files are not alongside the po files but two directories up,

For the record, that's an incredibly stupid idea on their part (if that actually is CakePHP's requirement). Why? Because entries in the PO(T) contain references — i.e. relative(!) filenames and line numbers — to where the strings are used in the code; this information is used by some translators to better understand the context. If you put POs created from the POT into a different directory, you completely break all the references. </rant>

Before I patched, I tried adding the path to the POT file to the Source Paths,

To be honest, that makes even less sense. To be clear, while I'm reluctant to add X-Poedit-Potfile, I may still come around after thinking about it some more.

Maybe something can be done there?

What about something like this?

1. If the source search paths are defined, behave as now.
2. Otherwise, when the user clicks update, try to find a suitable POT file and ask the user if Poedit should update from that file or would like to pick another POT file. (And perhaps use non-required X-Poedit-Potfile as a hint here.)
3. Remember the choice (not in the PO file, but in some persistent cache) and make that the default next time around.
4. Maybe even add a "Don't ask again" checkbox and show the setting in catalog properties.

I don't know anything about the OSX Sandbox rules, but is doesn't feel that different from going through the sources of a project?

What I meant was that in the sandbox, the user needs to explicitly choose files/directories that the application may access. For sources scanning, I do this by asking for the permission to the entire source tree, but if all I need is access to a single POT file, it's better to ask the user only for that (and speaking as a user, I wouldn't feel comfortable if an app I use demanded more permissions than it apparently needed).

Anyway, the above scheme is sandbox friendly, but more importantly, I think it's also better in that it works with any POs and also makes it clear what's going on. What do you think?

The suggested steps seem fine. I don't think I mind where Poedit stores the POT-PO relation...
It would be nice if one could "enter through" the dialog when de suggested file is correct.

All together it would streamline my workflow a lot.

I'll see if I can relay your opinion to the CakePHP developers :-)
Poedit doesn't seem to mind and finds the source files for both the PO and the POT files.

Hi!

TL;DR:

• I agree with @joostdekeijzer that selecting the source file on every update is a pain (i'm now cleaning my translations, so i update the .pot file on every small change in my sources), so it would be nice to have a way of storing the path to a .pot file somewhere
• And I totally agree with @vslavik about not storing the reference in the translations but maybe it should be done in the catalog manager. This way, the system should work great for any file organization.

If this functionality seems interesting enough, I'll open a feature request issue.

Longer thing about CakePHP and its translation system
To understand why CakePHP behave like this, we must be aware of how it works. CakePHP have support for domain strings, which allows developpers to split their translations between functionalities ('core' domain for CakePHP core strings, then you can have as many domain as you need, creating them in the sources.). With this system, we can use multiple translations of the same string between different sections of the application (ie, string 'Posts' for domain admin can be translated 'Posts' for another domain, and 'Articles' in another one)

When CakePHP i18n functionnality extracts the strings from the sources to create the .pot files, the relative path is well kept, so there is no issue with bad sources links in Poedit. The "weird" part may be the following structure:

Locale/
  + <domain>.pot files (extracted from sources, may be language agnostic)
  + fr_FR/ (actual translation)
     + <domain>.mo files
     + <domain>.po files
  + en_EN/ (actual translation)
     + <domain>.mo files
     + <domain>.po files
  + ...

It's done this way because of the number of possible domains and the fact that cake looks in the Locale/<language> folder to load the translations.

I'll open a feature request issue.

Don’t open any duplicates, please. You’re free to open a pull request actually implementing it, though.

FWIW, I don’t recommend doing it in the manager: it’s an unmaintained, deprecated piece of crap. There’s really no reason why this shouldn’t be autodetected smartly as per my previous comment (including a CakePHP special case, because it’s no trouble for Poedit to look one level up for a POT if it can’t find it alongside the translation file).

Longer thing about CakePHP and its translation system

None of this has bearing on this issue and is run-of-the-mill standard use of domains (modulo possible abuse of them when the same source tree — i.e. a domain — is artificially split into multiple gettext domains) and doesn’t really explain the peculiar choices (both standard Unix approach and WordPress’ one are domains-aware, yet don’t need to do this).

With this system, wa can use multiple translations of the same string between different sections of the application

(BTW, I recommend reading up on “message contexts”, a long-time standard gettext feature that is actually meant for exactly this particular purpose…)